Die Ultimative Software-P…i Collection 1996 & 1997/Die Ultimative Software-Pakete CD-ROM fur Atari Collection 1996 & 1997.iso/d/diskmoni/dump_as/konzept.txt

Text File | 1996-11-17 | 23.9 KB | 452 lines

Alexander Scheutzow
Berliner Str. 20
W 6800 Mannheim 1
Deutschland


         ;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~;
         |                     D U M P _ A S                     |
         |                     -------------                     |
         |     Der Dateien-, Laufwerks- und Speichermonitor.     |
         '~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~'

Textdatei "KONZEPT.TXT" zur Shareware-Version 1.00, Stichtag 1. 6. 1992.

Bitte studieren Sie zuerst die Datei "LIESMICH.TXT", die sich mit der
Bedienung von DUMP_AS, Share-Bedingungen usw. befaßt. Angehende Aufsteiger
sollten parallel dazu und zum Rest dieses Textes das MINI-GLOSSAR am Ende
dieser Datei verwenden, als Vorgeschmack auf das notwendige Bücherstudium.
Hier möchte ich einige ergänzende Hinweise und Informationen geben, die
Sie vielleicht nicht zusammen mit der Anleitung ausdrucken möchten. Das
Niveau der vorausgesetzten Kenntnisse wird stark schwanken, wie schon im
LIESMICH; bitte sehen Sie es mir nach, wenn Sie hier und da unter- oder
überfordert sind. Hoffentlich ist auch für Sie etwas dabei, ansonsten
warte ich auf Ihre Anregungen.

Die meisten Anmerkungen zur Datensicherheit sind wegen der Wichtigkeit des
entsprechenden Bewußtseins ins LIESMICH übergesiedelt.


1) Geschichte und Implementation

Wie so viele Shareware, ist auch DUMP_AS ein Evolutionsprodukt aus
mehreren kleinen Werkzeugen, die ad hoc entwickelt und später verbunden
wurden. Solche Keimzellen, teils in BASIC geschrieben, waren die
Text-Anzeige 't', der Hauptmodus und die Vergleichsfunktion 'c'.
Irgendwann wurde eine Zusammen-Fassung in C (Turbo-, jetzt Pure-C) und
Assembler (dto.) fällig, die in kurzer Zeit gigantische Formen annahm, da
mir immer neue Ergänzungsmöglichkeiten einfielen. Ein guter Teil des
Wildwuchses wurde wieder abgespeckt, da jedes zusätzliche Byte
Programmcode oder Blockspeicher den Laderäumen verloren geht.


2) Konzept der Oberfläche

Auf speicherfressende, lahme und anfällige Schnörkel verzichte ich
möglichst, dafür sollen aussagekräftige Dialoge eine Fehlbedienung
unwahrscheinlich machen. Luxus-Menüs mit kryptischen Bezeichnungen wurden
vermieden bzw. wieder hinausgeworfen. Vom ganzen AES-Zauber ist nur die
Datei-Auswahl-Box übriggeblieben, die wohl zu den elementaren
Menschenrechten zu zählen ist. Der Ungeübte wird die Bedienung zunächst
für mühsam halten, da die auslösenden Tastenkombinationen gelernt oder im
'Help'-Text nachgeschaut werden müssen. Dafür sind die Modalitäten und
Parameter einer jeden Tastenfunktion in den Dialog-Rückfragen möglichst
klar benannt, so daß hier kaum weiterer Lernaufwand entsteht. Bei manchen
Programmen erscheint, wenn Sie versehentlich mit dem Ellenbogen auf die
Tastatur geraten, eine unheilverkündende Biene auf dem Bildschirm, und
nach drei Minuten sind alle Achtelnoten in Pausen umgewandelt unter
Verlust der Tonhöhe; nicht so bei DUMP_AS. Für Kommentare dazu bin ich
dankbar.


3) Geschwindigkeit vs. Sauberkeit

Großen Aufwand habe ich zur Beschleunigung von Operationen wie Blättern
und Rollen getrieben, weil erst hierdurch die schnelle Übersicht
ermöglicht wird, die DUMP_AS so brauchbar macht. Dazu erwies es sich aus
den bekannten Gründen als unumgänglich, den Bildschirmspeicher direkt zu
manipulieren. Den Preis, der dafür zu zahlen ist, ist die Einschränkung
der Hardware, wie im LIESMICH angegeben: DUMP_AS läuft nur auf (MEGA)
ST(E) in der hohen Auflösung 640*400, es sei denn, man verfügt (z.B. auf
TT oder Falcon) über eine ST-Ämulation, ggf. einschließlich
Monochrom-Konversion, die "Line A +/-", XBIOS ("Setscreen" u.ä.) und die
dokumentierten ST-Systemvariablen unterstützt. Mir ist so etwas noch nicht
bekannt, es scheint mir aber in der Luft zu liegen angesichts der vielen
ST-Spiele und anderen zeitkritischen (daher "unsauberen") ST-Programme.
Vielleicht schreiben Sie es: im VBI wird der XBIOS-"physische Bildschirm"
in das wirklich sichtbare Fenster übertragen.


4) Schwerpunkte der Ausstattung

Wie Sie gemerkt haben werden, macht DUMP_AS von sich aus keinen
Unterschied zwischen verschiedenen Datei-Arten. Ein gewisser Schwerpunkt
bei der Gestaltung der Funktionen ist jedoch die Interpretation als
Bilddaten, ein anderer das Herausfiltern von Texten. Zur Beantwortung
folgender und verwandter Fragen eignet sich DUMP_AS besonders:

- Was für eine (Daten-)Datei ist das?
- Was steht genau drin (z.B. nicht druckende Zeichen)?
- Was tut dieses PRG (welche Texte gibt es aus)?                     ['t']
- Wie arbeitet dieses PRG?                                      ['Ctl.-p']
- Welche (gelöschten) Daten befinden sich auf dem Speichermedium?
- Wie sehen die Sprites/Bilder in Ruhestellung aus?        ['v' etc., 'F']
- Wie sieht das Bild/der Zeichensatz etc. insgesamt aus?   ['w', '<' etc.]

Der Plan, einen Disassembler zu integrieren (wie in einem
"Konkurrenzprodukt"), wurde fallengelassen, da er, gemessen an seiner
Aussagekraft, die Sache zu sehr aufgebläht und zu viel Speicherplatz
verbraten hätte. Gute Disassembler gibt es ebenso wie Grafikprogramme,
Editoren und Diskettenärzte in vielen Ausfertigungen und Preislagen, daher
wäre es unnötig, DUMP_AS mit deren Aufgaben zu belasten. Die betreffenden
Daten mit DUMP_AS zu isolieren und als Datei abzuspeichern, dann mit den
betreffenden Programmen zu bearbeiten und evtl. mit DUMP_AS wieder
einzufügen, ist eine einfache und mächtige Methode. Daher wurde auf
folgende Manipulationsmöglichkeiten Wert gelegt:

- Daten identifizieren und (als Datei oder Laderaum) isolieren,
- Daten zusammenfassen, z.B. gelöschte Dateien,
- Kleine Änderungen ("Patches") direkt vornehmen, auch im RAM außerhalb
der Laderäume,
- Daten in ein anderes Format bringen, z.B. einen Header voranstellen,
- Kleine Dateien schnell neu schreiben/malen,
- Daten aus verschiedenen Quellen neu kombinieren,
- Disk-Sektoren überschreiben.

Ins ROM springen kann man in dieser Version nicht mehr, da es sicherer und
problemlos ist, sich ein Datei-Abbild davon zu schaffen. Darin kann man
dann mittels 't' die Infantilitäten bewundern, die den Platz für die
vermißten Tastenfunktionen verbraten:

      Ich brennt' es gern in jedes ROM-TOS ein,
      Ich ätzt' es gern auf jeden Chip-Baustein,
      Ich löt's in jedes ST(E)-Gerät,
      Auf daß es DUMP_AS jedermann verrät...


5) Kurz etwas zum Patchen

Unter Patchen versteht man das Verändern einzelner Stellen in einer
.PRG-Datei unter Wahrung der Gesamtlänge und der Adreßrelationen. Im
Unterschied dazu könnte man das veränderte Reassemblieren eines
Programmcodes als "Hacken" bezeichnen. Abänderungen jeder Art können
unvorhersehbaren Schaden anrichten sowie Urheberrechte verletzen.
Andererseits sind manche Programme mit tödlichen Fehlern behaftet, die
nicht sofort von den Autoren behoben werden, so daß der Benutzer auf
Patches angewiesen ist. Atari geht hier mit "leuchtendem Beispiel" voran,
indem einige Patches sogar autorisiert werden, und zwar kurz nach
Fertigstellung der betreffenden TOS-Version.

Eine dringende Ermahnung als Minimalforderung: Kennzeichnen Sie alle
gepatchten Dateien, auch wenn sie nur für Ihren eigenen Gebrauch bestimmt
sind! Wenn irgend möglich, stellen Sie sie in eigene Ordner. Wenn Name und
Pfad beibehalten werden müssen, bewahren Sie die Original-Datei direkt
daneben, z.B. mit der Endung .ORI. Dokumentieren Sie die Änderung aufs
genauste durch ein PATCH.DOC im gleichen Ordner. Wenn Sie fremde
PD/Shareware weitergeben, bei der Sie Änderungen für nötig halten,
unbedingt das komplette Original weitergeben!! Am besten beschreiben Sie
den Patch lediglich in einer gut abgetrennten Dokumentation samt
ausführlicher Begründung. Hat der Empfänger DUMP_AS im Haus (oder
mitgeliefert bekommen), wird er die Verbesserung schnell selbst vornehmen
können, wenn sie ihm einleuchtet. Vorsicht ist immer angebracht.
Progrämmchen, die Patches auch in kommerziellen Produkten eigenständig
anbringen, sind weit verbreitet, aber ebenfalls nicht zu empfehlen, u.a.
wegen Virengefahr. Auch hier sind aufklärende Textdateien vorzuziehen.



                       ANWENDUNGSBEISPIELE:


6) Wie finde ich in den Disk-Sektoren ein Verzeichnis oder einen
Dateianfang? Was ist beim Reparieren zu beachten?

Wenn man auf dem ersten Buchstaben eines Verzeichnis-Eintrags positioniert
ist, geht man mit 'r' ins Rechen-Menü und gibt dort

        ci(p+26)

ein. Nachdem mit 'Return' diese Position errechnet ist, kann man 'p'
drücken, um sie aufzusuchen; es ist die gesuchte Stelle. Pech hat man,
wenn die Positionsangabe nicht reagiert, dann ist das betreffende Cluster
nicht eingeladen. Man gibt dann also nur

        i(p+26)

ein und lädt dann das Cluster mit der Nummer ein, die das Resultat
bezeichnet.

Auf diese Weise kann man sich meistens schnell vom Wurzelverzeichnis bis
zum Dateianfang hangeln, oft auch bei (frisch) gelöschten Dateien/Ordnern.
Übrigens erfährt man die Dateilänge in der gleichen Situation mit der
Zauberformel I(p+28).

Weitere Anwendungen dieser Methode: Ordner umhängen (unbedingt
"beidseitig", d.h. den betreffenden Zwei-Punkte-Eintrag auch abändern)
oder umbenennen, falls Ihr TOS das nicht kann und Sie sich mit den
Verzeichnissen gut auskennen - das Schema ist praktisch identisch mit dem
von MS-DOS benutzten. Wer auf Sicherheit Wert legt - und das tun Sie
doch?! - wird möglichst nur einzelne Sektoren zurückschreiben und für den
Fall der Fälle jede größere Aktion schriftlich protokollieren.
Sicherheitskopien schaden ebenfalls nicht. Siehe Abschnitt 9 des LIESMICH.

Auch beim Wiederherstellen korrumpierter Verzeichnis- und FAT-Daten
erweist sich das 'r'-Menü dem Kundigen als hilfreich. Diese etwas
mühselige Prozedur ist oft auch dann noch erfolgreich, wenn ein noch so
"intelligenter" Diskettenarzt versagt, da dieser, genau wie
Menschen-Ärzte, Ihren Fall nicht so gut kennt wie Sie und folglich
vielfach von pauschalen Hypothesen ausgeht. Vor allen Rettungsversuchen
möglichst eine genaue Kopie des Anfangszustandes anfertigen. Beim
Scheitern Ihrer Bemühungen können Sie eine weitere (!) Kopie davon einer
Super-Koryphäe aus Ihrem Bekanntenkreis anvertrauen. Versucht man, auf ein
verdächtiges Medium etwas zu schreiben, seien es Dateien oder Sektoren,
vergrößert sich höchstwahrscheinlich der Schaden, wenn man nicht (dank
DUMP_AS und eigenen profunden Kenntnissen) genau weiß, was man tut.


7) Welcher Abschnitt hat welchen Inhalt? Wie finde ich Bilder?

Die meisten Programm-Dateien haben gegen Ende einen "Daten-Bereich", in
dem u.a. Texte und Bilder gespeichert werden. Namentlich gewöhnliche
(längere) ASCII-Texte erkennt man sehr schnell und einfach bereits im
b-Modus; 'Ctl.-ü' oder aber 't' sind ebenfalls dienlich.

Bilder sucht man zuerst dort in der Nähe mit dem b-Modus. Kennt oder ahnt
man deren Breite (z.B. bei s/w-Sprites 2), so stellt man diese ein ('#',
ggf. danach 'w') und blättert umher. So findet man in Sekunden jedes
Sprite, jedes Ikonogramm und jeden Mauszeiger.

Bei unbekannter Breite ist man wieder auf seinen erfahrenen Blick
angewiesen (nebst geeigneter Breiteneinstellung, 12 mit 'w' hat sich oft
bewährt), um die Stelle zu erraten. Hat man eine solche im Verdacht,
stimmt aber die Breite nicht, so positioniert man sich (per Mauszeiger)
auf eine Stelle, rechts von der man markante senkrechte Strukturen
vermutet. Jetzt ggf. die 'w'-Funktion mit 'Return' verlassen und mit 'v'
einen Vorschlag anfordern. Hat dies nicht den gewünschten Effekt, nochmal
probieren (bis sich die Breite nicht mehr ändert), ggf. die Position
korrigieren. Eine recht sichere Strategie ist, mit Breite 2 anzufangen und
fortgesetzt 'V' zu drücken, dann werden alle geraden Breiten
durchprobiert. Sollte die gesuchte Breite ungerade sein, so wird man das
Bild dennoch zusammengepreßt erkennen; dann die Breite mit 'd2' halbieren.
Oft ist das Bild schon schemenhaft und senkrecht/waagrecht verzerrt zu
sehen, wenn die Breite z.B. um einen Faktor 5/3 verfehlt wurde. Dann führt
manchmal 'Ctl.-v' zum Ziel, oder auch Probieren von Faktoren und Divisoren
(z.B., falls die momentane Breite durch 7 teilbar ist, 'd7' versuchen;
geeignete Faktoren sind manchmal im g-Modus als senkrechte Pixel-Abstände
ähnlicher Zeilen abzuzählen). Scheint das Resultat mißlungen, kann mit
'Sh.-Undo' die vorige Breite restauriert werden, um z.B. eine andere
Position auszuprobieren.

Die Vorschlags-Mechanismen sind keineswegs nur dazu geeignet, Bilder,
Ikonogramme, Sprites, Mauszeiger und Zeichensätze darzustellen, vielmehr
kann man damit allerlei fast-periodische Strukturen ermitteln. Beispiele
sind die erwähnten Verzeichnisse, Listen und Felder aller Art, sowie
ausgeschriebene Schleifen im Programmcode. In derartigen Fällen bietet
sich der ü-Modus an, etwa mit dem Zeichensatz ASCI_HEX.FN8, doch ist für
den Geübten auch der b-Modus von Nutzen.


8) Ein Programm findet seine Dateien nicht

Stürzt ein Programm gleich zu Anfang ab, oder erscheint eine Warnmeldung
der Art "Spielfiguren nicht gefunden!", so liegt das eventuell daran, daß
Hilfsdateien woanders gesucht werden, als dort, wo Sie sie hinkopiert
haben. Laden Sie so eine Programmdatei in DUMP_AS ein und betätigen 't'
(dabei natürlich die Zeichen '\', ':', '*' und '?' sowie alle Buchstaben
zulassen). Achten Sie auf mögliche Ordner-, Datei- oder Pfadnamen. Beginnt
ein solcher mit '\', also z.B. "\DATEN\COLOR\", so erwarten das Programm
wahrscheinlich unverschämterweise, daß Sie seinen läppischen Ordner
"DATEN" in Ihrem geheiligten Wurzelverzeichnis stehen haben. Wenn Sie
solchen Zumutungen nicht gehorchen wollen, stellen Sie den Ü-Modus ein,
klicken Sie mit 'li.' den ersten '\' an und tippen Sie (im Beispiel)
"DATEN\COLOR\" ein, also ohne den führenden '\'. Solch ein Pfad wird mit
einem Null-Byte abgeschlossen sein, tippen Sie also mit 'Ctl.-00' ein
solches über das noch vorhandene alte Zeichen am Ende (hier ebenfalls ein
'\'), und klopfen Sie diese Änderung mit 'Return' fest. Jetzt endet der
Pfad mit zwei Null-Bytes, was nichts schadet. Er bezieht sich aber nun für
das GEMDOS auf das aktuelle Verzeichnis, wahrscheinlich also das, worin
auch die Programmdatei steht. Nachdem Sie also den Laderaum abgespeichert
haben (wie immer auf eine Kopie oder unter neuem Namen!), kopieren Sie den
Ordner "DATEN" in jenes Verzeichnis hinein. Bei Mißerfolg den
ursprünglichen Zustand wiederherstellen und evtl. weiter probieren.
Achtung: Dies ist als Anregung, nicht als Kochrezept zu verstehen! Wer mit
dem GEMDOS nicht so recht vertraut ist, sollte sich von einem erfahrenen
AtariSTen helfen lassen (vorher aber alles auf Disketten kopieren und
diese gut verstecken!).


9) Ein besonderer Tip für Programmierer: das Buddelschiff

Wie kommt das kleine Bildchen in die DUMP_AS.PRG-Datei? Manche
Programmiersprachen haben einen speziellen Befehl "INLINE" für solche
Zwecke. Bietet Ihr Compiler diese Möglichkeit nicht, stattdessen aber -
als Linker - das Zusammenbinden von Objektdateien, so können Sie in
Zukunft trotzdem auf das Eintippen seitenlanger Initialisierungsdaten wie
auch auf das Nachladen zur Laufzeit verzichten. Nehmen wir an, Sie haben
1234 Bytes Daten bereits in einer Datei stehen, z.B. ein Bild, und Sie
haben einen C-Compiler. Legen Sie ein Modul MEINBILD.C an, das nur
folgenden Text enthält:

        char mein_tolles_bild[1234] = "hier fängt's an";

(also ein teilweise initialisiertes Feld von Bytes der Dimension 1234) und
übersetzen Sie es zu der Objekt-Datei MEINBILD.O. Diese Datei laden Sie in
DUMP_AS ein, in den anderen Laderaum Ihr Bild, dessen 1234 Bytes Sie nun
dorthin kopieren, wo Sie in MEINBILD.O lesen: "hier fängt's an", gefolgt
von 1219 Null-Bytes (brauchen Sie nicht nachzuzählen). In Ihrem
eigentlichen C-Programm deklarieren Sie den Feldnamen global, wie üblich:

        extern char mein_tolles_bild[];

und schon greifen Sie auf die Daten zu, als hätten Sie sie eingetippt.
Natürlich müssen Sie MEINBILD.O (nicht MEINBILD.C!) vom Linker einbinden
lassen, indem Sie es im Makefile (der Projekt-Datei) oder dem
Link-Kommando angeben.

Hat ihr Entwicklungswerkzeug keinen Linker, können Sie notfalls auch im
fertigen .PRG eine mit einem markanten Text initialisierte Zeichenkette
('s') überschreiben, dies muß dann aber nach jedem Kompilieren erneut
geschehen. Ist eine Längenangabe nicht möglich oder füllt Ihr Compiler
nicht mit Nullbytes auf, so müssen Sie die volle Anzahl Zeichen im
Quelltext eintippen. Sollte auch dies wegen zu großer Länge unmöglich
sein, hilft vielleicht der Perioden-Trick weiter: Tippen Sie etwa ein:

    STRING kette(100)    (* als Feld von Zeichenketten dimensionieren *)
    kette(1) = "0123456789"
    kette(2) = "0123456789"
    ...

usw. (kopieren) je nach Sprache; diese Zeichenketten müssen Sie dann im
Programm als Rechteck ausfindig machen und mit 'K' übermalen.


10) Ergänzendes zu den Zeichensätzen:

Das .FN8-Format ist identisch mit dem von STAD benutzten, folglich ist der
STAD-Zeichensatz-Editor auch hierfür brauchbar. Einen .FN4- oder
.FN6-Zeichensatz können Sie damit ebenfalls herstellen: Setzen Sie die
Zeichen in passender Größe in die linke obere Ecke des jeweiligen Platzes;
das Ergebnis laden Sie in einen DUMP_AS-Laderaum und extrahieren die
benötigten Bytes mittels 'K' in den anderen Laderaum. Die Details
herauszufinden, überlasse ich Ihnen als Denksport.

Der TEMPUS-Editor und DEGAS verwenden dasselbe Format, dulden allerdings
fehlende Zeichen am Ende, wie mir berichtet wurde. Sicher gibt es weitere
Zeicheneditoren dafür; übrigens hat auch DUMP_AS Talent für derartige
Aufgaben ('g').


11) Link-Viren, voreingestellte Variablen

Manche Programme erlauben es, die Voreinstellung von Parametern (z.B. der
Seitenbreite und -länge in Textverarbeitungsprogrammen) zu ändern und
speichern diese dann in der Programmdatei selbst ab. Wird dann ein guter
Viren-Wächter eingesetzt, so wird er melden, daß die Datei verändert ist.
Umgekehrt kann theoretisch ein Link-Virus so programmiert sein, daß es die
von Ihrem Detektor errechnete Prüfsumme unverändert läßt und infizierte
Programme daher nicht beanstandet werden. Um ganz sicher zu gehen, lädt
man die betreffende Datei in den einen Laderaum, das Original von der
Diskette (oder eine Kopie, in der unter aseptischen Bedingungen die
erwähnten Parameter angeglichen wurden) in den anderen. Im Parallelmodus
('p') vergleicht man die Dateien ('c'), um ggf. zu beurteilen, ob die
unterschiedlichen Stellen ein Link-Virus darstellen. Experimentieren Sie
eventuell mit den Parametern, um deren Ort in der Datei zu herauszufinden.
Einzelheiten über Viren sollten Sie der Literatur entnommen haben oder
entnehmen.

Das Problem, ob Konfigurations-Parameter in der Programm-Datei oder in
einer separaten Datei hinterlegt werden sollen - beides hat große
Nachteile - ist bei DUMP_AS nach reiflicher Überlegung dahingehend gelöst,
daß gar keine Änderung der Voreinstellung vorgesehen ist.

Wer auf die parametrische Selbstbestimmung auch in so einem Fall nicht
verzichten zu können meint, muß eben versuchen, zu "patchen" - auf die
Gefahr unerwünschter Nebenwirkungen hin; siehe oben und im Liesmich
Abschnitt 18. Diese Gefahr steigert sich zur Apokalypse, wenn Sie Werte
eintragen, die im Programm selbst nicht zur Auswahl stehen. In DUMP_AS
gebe ich (allerdings inoffiziell und auf eigene Gefahr) die Voreinstellung
der von der 't'-Funktion zu akzeptierenden Sonderzeichen frei, sie ist als
Zeichenkette abgespeichert, die mit "äöü" beginnt und - für diesen Zweck -
mit ein paar Leerzeichen endet; Doubletten schaden nämlich nicht.
Vorangestellt sind zwei Zeichen, die die Voreinstellung des Trenn- bzw.
Nummernzeichens enthalten. Überschreiben Sie keinesfalls das abschließende
Nullbyte und setzen Sie kein anderes Nullbyte ein! Befolgen Sie Abschnitt
5 oben, insbesondere geben Sie unbedingt nur das Original an andere
Personen weiter!


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

MINI-GLOSSAR:

- Sektor: Die üblichen Massenspeicher werden beim Formatieren in Sektoren
gleicher Länge (meist 512 Bytes nutzbare Daten) unterteilt, die noch mit
etwas Sicherheits-Brimborium umzäunt sind. Ihr Computer kann
Massenspeicher-Daten nur sektorenweise lesen und schreiben. Die Sektoren
zu einem "logischen Laufwerk", z.B. einer Festplatten-Partition, werden ab
0 durchnumeriert ("logische Sektornummer"). Die Nummer 0 gebührt
normalerweise dem "Bootsektor", der einige fundamentale Daten über das
Laufwerk enthält. TOS ist allerdings bereit, sich von entsprechender
Software, dem Speichermedien-"Treiber", das Vorhandensein von Sektoren
lediglich vorgaukeln zu lassen; auch die Information, die der Bootsektor
bereitstellen sollte, kann anderweitig untergeschmuggelt sein, wie z.B.
bei einer Ramdisk, die oft nicht einmal einen "logischen" Bootsektor
aufweist. Die Sektor-Funktionen von DUMP_AS stellen sich auf denselben
Standpunkt wie TOS, behandeln also "logische Sektoren" auch aus Ramdisks.

- Cluster: Um die Verwaltung der Dateien zu rationalisieren, wird ihnen
der Platz auf dem Laufwerk nur in Blöcken von je (meist) zwei Sektoren
zugewiesen, fachchinesisch Cluster genannt.

Die erwähnten Zahlen, in der Regel 512 und 2, sind im Bootsektor
niedergelegt, falls dieser existiert. Befindet man sich in DUMP_AS am
Anfang desselben, so ergibt im Rechen-Menü 'r' die Formel i(p+11) die
erstere und B(p+13) die zweite. Diese Stellen sind nötigenfalls zu
reparieren, um die anderen Sektoren überhaupt wieder lesbar zu machen.

- FAT: Datei-Zuweisungs-Tabelle. Zahlenkram in den Sektoren nach dem
Bootsektor, worin niedergelegt ist, in welcher Reihenfolge die belegten
Cluster inhaltlich aufeinanderfolgen.

- Wurzelverzeichnis: Liegt auf den Sektoren dahinter. Jeder Ordner und
jede Datei des Laufwerks, die in keinem (anderen) Ordner enthalten sind,
sind hier aufgelistet, und zwar mit Namen und Endung (zusammen 11 Bytes),
sowie mit weiteren 21 Bytes Verwaltungszahlen, aus denen u.a. hervorgeht,
in welchem Cluster die Datei anfängt (siehe oben Abschnitt 6). Zusammen
mit der FAT-Information weiß das GEMDOS oder MS-DOS dann, welche Cluster
in welcher Reihenfolge die Datei ausmachen. Bei Ordnern erfährt man
stattdessen, in welchem Cluster das betreffende Unterverzeichnis beginnt.
Die Numerierung derjenigen Cluster, mit denen sich die FAT befaßt, beginnt
erst hinter dem Wurzelverzeichnis, und zwar mit Cluster 2 (don't ask me
why; was gestern provisorische Willkür war, wird heute zum Sachzwang
erklärt, wie in der Politik).

- Unterverzeichnis: Darf im Gegensatz zum Wurzelverzeichnis beliebige
Länge haben, da die benötigten Cluster, wie bei Dateien, von der FAT
erfaßt werden (folglich ist bei mehr als 32 Einträgen nicht garantiert,
daß es zusammenhängend gespeichert ist). Ansonsten ist es genau wie das
Wurzelverzeichnis aufgebaut, wobei der erste Eintrag den Namen "." trägt
und die Theaterfrage "wo bin ich?" sowie die Fernsehfrage "was bin ich?"
beantwortet, der zweite namens ".." verweist auf das übergeordnete
Verzeichnis, also im Pfad um eine Station zurück.

Einige Details finden Sie oben in Abschnitt 6; zur FAT usw. muß ich Sie
auf die umfangreiche Literatur verweisen (Titel mag ich nicht nennen).

- GEMDOS-Speicherverwaltung: Programme können vom Betriebssystem
Speicherblöcke anfordern, d.h. zum exklusiven Gebrauch reservieren lassen,
sowohl durch den Willen des Programmierers als auch den seines Compilers
oder Interpreters, ferner von Accessories, Dateiauswahl-Boxen etc..
Normalerweise werden diese Blöcke, soweit nicht schon zurückgegeben, nach
Programmende wieder für frei erklärt. Zu möglichen Pannen lesen Sie bitte
Abschnitt 19 im Liesmich.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Diese Datei wird laufend erweitert, gerne auch um Extrakte aus Ihren
Erfahrungsberichten und Hinweisen, auf die ich sehr gespannt bin.


_AS.